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(57) Abstract 

A method preserving an original timestamp value in a packet (70) of data to be transmitted from a transmission site to a reception 
site wherein the original timestamp value may require adjustment at the reception site to account for delays experienced by that packet (70) 
during multiplexing and/or transmission. The method comprises the steps of (a) denning at least first (88) and second (96) fields within the 
packet (70); (b) inserting, at the transmission site, an original timestamp value in the first field (88) of the packet (70), and thereafter not 
modifying the value in the first field (88); and (c) adding the value of any multiplexing or transmission delays experienced by that packet 
(70) to an initial value in the second field (96). At the reception site, the second field (96) will reflect any delays experienced by the packet 
(70) while the original timestamp value is preserved in the first field (88). 
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METHOD FOR PRESERVING THE ORIGINAL TIMEBASE 
OF A PROGRAM IN A MULTIPLEXED COMMUNICATIONS SYSTEM 

FIELD OF THE INVENTION 

The present invention relates to digital 
transmission systems, and more particularly, to a method for 
preserving the original timebase of a digital program in a 
5 transmission system that employs an adjustable timestamp 

technique for performing clock recovery at a reception site. 

BACKGROUND OF THE INVENTION 

Recently, the International Organization for 

10 Standardization (ISO) adopted a standard protocol for 

combining one or more "elementary streams" of coded video, 
audio or other data into a single bitstream suitable for 
transmission. The standard, hereinafter referred to as the 
"MPEG-2 Systems" standard, is described in detail in the 

15 MPEG-2 Systems Committee Draft (ISO/IEC JTC1/SC2 9/WG11/N0 601 , 
November, 1993) thereinafter "MPEG-2 Systems Committee 
Draft"], which is hereby incorporated by reference. An 
overview of the MPEG-2 Systems standard is provided in 
Wasilewski, The MPEG-2 Systems Specification: Blueprint for 

20 Network Interoperability (January 3, 1994), which is also 
hereby incorporated by reference. The MPEG-2 Systems 
standard provides a syntax and set of semantic rules for the 
construction of bitstreams containing a multiplexed 
combination of one or more "programs." A "program" is 

25 composed of one or more related elementary streams. An 

"elementary stream" is the coded representation of a single 
video, audio or other data stream that shares the common 
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timebase of the program of which it is a member. For 
example, in the context of a subscription television system, 
a "program" may comprise a network television broadcast 
consisting of two elementary streams: a video stream and an 
5 audio stream. 

As development of the MPEG-2 Systems standard 
progressed, a two- level packet -based multiplexing scheme 
emerged. At the first level, each elementary stream to be 
transmitted, i.e., the coded data for one video, audio or 

10 other data stream, is packetized to form a Packetized 
Elementary Stream (PES) . Each PES packet in a given 
Packetized Elementary Stream consists of a PES packet header 
followed by a variable length payload containing the coded 
data of that elementary stream. The Packetized Elementary 

15 Stream structure provides a means for packaging subparts of a 
longer elementary stream into consecutive packets along with 
associated indicators and overhead information used to 
synchronize the presentation of that elementary stream with 
other, related elementary streams (e.g., elementary streams 

20 of the same program) . Each Packetized Elementary Stream is 
assigned a unique Packet ID (PID) . For example, the 
Packetized Elementary Stream containing the coded video data 
for a network television program may be assigned a PID of 
"10"; the Packetized Elementary Stream containing the 

25 associated audio data for that program may be assigned a PID 
of "23", and so on. 

At the second level, one or more Packetized 
Elementary Streams may be further segmented or "packetized" 
to facilitate combining those streams into a single bitstream 

3 0 for transmission over some medium. Ultimately, two different 
"second level" protocols for combining one or more Packetized 
Elementary Streams into a single bitstream emerged: 1) the 
Program Stream (PS) protocol and 2) the Transport Stream 
protocol. Both stream protocols are packet-based and fall 

35 into the category of "transport layer" entities, "as defined 
by the ISO Open System Interconnection (OSI) reference model. 
Program Streams utilize variable- length packets and are 
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intended for "error-free" environments in which software 
parsing is desired. Program Stream packets are generally 
relatively large (IK to 2K bytes) . Transport Streams utilize 
fixed length packets and are intended for transmission in 
5 noisy or errored environments. Each Transport Stream packet 
comprises a header portion and a payload portion. Transport 
Stream packets have a relatively short length of 188 bytes 
and include features for enhanced error resiliency and packet 
loss detection. The remaining background discussion will 
10 focus primarily on the MPEG-2 Transport Stream protocol. 

As finally adopted, the Transport Stream protocol 
provides a standard format (i.e., syntax and set of semantic 
rules) for combining one or more Packetized Elementary 
Streams into a single "Transport Stream" that may then be 
15 transmitted over some medium. Figure 1 graphically 

illustrates the generation of an MPEG-2 Transport Stream from 
a plurality of Packetized Elementary Streams. As 
illustrated, the individual packets of each Packetized 
Elementary Stream are segmented and inserted into the payload 
20 sections of successive Transport Packets. For example, as 
illustrated in Figure 1, one of the PES packets 10 of the 
Packetized Elementary Stream containing the coded video of 
elementary stream "Video 1" is segmented and inserted into 
the payload sections of consecutive Transport Packets, e.g. 
25 12 and 14. Every Transport Packet has a header, e.g., header 
16 of Transport Packet 12, and the header of each Transport 
Packet contains the PID associated with the Packetized 
Elementary Stream carried in that Transport Packet. In the 
example illustrated in Figure 1, the Packetized Elementary 
3 0 Stream carrying the coded video of elementary stream "Video 

1" has been assigned a PID of '10', and therefore, the header 
of each Transport Packet 12, 14 carrying data from that 
Packetized Elementary Stream will contain a PID value of 
'10'. Similarly, the headers of each Transport Packet 18, 20 
3 5 carrying Packetized Elementary Stream data for elementary 
stream "Audio 1" will contain the PID assigned to that 
elementary stream, which in the example shown is '23'. 
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The Transport Packets formed from each Packetized 
Elementary Stream are then multiplexed to form a single 
outgoing bitstream or "Transport Stream." Thus, a Transport 
Stream comprises a continuous sequence of Transport Packets, 
5 each of which may carry data from one of a plurality of 
Packetized Elementary Streams. At a decoder location, a 
given Packetized Elementary Stream can be recovered from the 
incoming Transport Stream by simply extracting every incoming 
packet whose header contains the PID assigned to that 

10 Packetized Elementary Stream. A group of related Packetized 
Elementary Streams (e.g. audio, video etc.) can be extracted 
to reproduce a complete "program." 

As the MPEG- 2 Systems standard developed, the MPEG- 
2 Systems Committee further decided that segmentation of each 

15 Packetized Elementary Stream into a respective sequence of 
Transport Packets is to be carried out by an encoder 
employing a common system clock that operates at a nominal 
frequency of 27.0 MHz. Decoders for receiving and presenting 
a selected program (i.e., a set of related elementary 

20 streams) will therefore need a corresponding system clock 

whose frequency of operation and absolute instantaneous value 
match those of the encoder. However, in practice, a 
decoder's free-running system clock frequency will rarely, if 
ever, match the encoder's system clock frequency exactly, and 

25 therefore, some method for synchronizing the decoder system 
clock with the encoder system clock is required. As the 
MPEG- 2 Systems standard developed, participants of the MPEG- 2 
Systems Committee suggested that synchronization of a 
decoder's system clock with the encoder's system clock 

30 (sometimes also referred to hereinafter as "clock recovery") 
be achieved through the use of timestamps, referred to in the 
MPEG-2 Systems Committee Draft as Program Clock References. 
A Program Clock Reference (PCR) is an actual "snapshot" of 
the encoder's system clock. According to the technique 

3 5 adopted, for each program carried in a given Transport 

Stream, PCR's must be generated at least once every 100ms and 
inserted into the Transport Packets carrying one of the 
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elementary streams that make-up that program. For example, 
as illustrated in Figure 1, PCRs 24 and 2 6 have been inserted 
into Transport Packets 12 and 14, which carry Packetized 
Elementary Stream data for the video elementary stream, 
5 "Videol", of "Program 1". Similarly, PCRs, e.g. PCR 28, have 
been inserted into the Transport Packets, e.g. packet 32, 
carrying Packetized Elementary Stream data for the video 
elementary stream, "Video 21", of "Program 21". 

As mentioned, for a given program, PCRs must be 
10 generated and inserted into the sequence of Transport Packets 
carrying one of the elementary streams of that program at 
least once every 100ms. Each PCR is an actual sample of the 
encoder system clock at the time the PCR was inserted into 
its respective Transport Packet, and therefore, the original 

15 PCRs inserted into the Transport Packets of a given program 
reflect the true timebase of that program. With such a 
times tamp approach, each program may have its own independent 
timebase, and therefore, there is no need to synchronize the 
timebases of different programs prior to multiplexing. 

20 Although the PCRs in the sequence of Transport 

Packets carrying Packetized Elementary Stream data for a 
given program represent the true timebase of the program 
prior to any multiplexing stages, the MPEG- 2 Systems 
Committee realized that as the Transport Packets for each 

25 elementary stream reach the Transport Stream multiplexer 22, 
certain packets may experience a variable delay during 
multiplexing since the multiplexer can only "send" one packet 
at a time. When a PCR bearing Transport Packet experiences a 
variable delay, the original PCR in that packet is no longer 

30 valid. Consequently, the transport stream multiplexer 22 
must "adjust" the original PCR to account for any variable 
delay imposed on that packet by the multiplexer. Note, 
however, that constant end-to-end delays will not invalidate 
the PCRs in a series of Transport Packets since each 

3 5 Transport Packet will experience that same constant delay. 

One way to adjust the PCR value in a packet that 
experiences a variable delay, and the method ultimately 
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adopted by the ISO, is to determine the amount of variable 
delay the packet experiences between the input and output of 
a multiplexer or other device, and then to add that delay 
time to the original PCR value as the packet leaves the 
5 device in the outgoing Transport Stream. As a result of this 
adjustment, the PCR's of a given program, no matter where 
they may appear in an outgoing Transport Stream, should 
reflect the absolute value of the encoder's system clock at 
the time the packets bearing those PCR's were inserted into 

10 the outgoing Transport Stream. 

Figure 2 graphically illustrates the need for 
adjusting PCR values to account for variable delays, such as 
multiplexing delays. As illustrated in Figure 2, two 
Transport Packet sequences, each formed from a different 

15 Packetized Elementary Stream, are provided to respective 

inputs of a Transport Stream multiplexer 22. One sequence of 
Transport Packets, e.g. packets A and B, carries the 
Packetized Elementary Stream data of an exemplary video 
elementary stream, "Video 3". The other sequence of 

2 0 Transport Packets, e.g. Packets C and D, carries the 

Packetized Elementary Stream data of an exemplary audio 
elementary stream, "Audio 7". As further illustrated, 
Transport Packets A and B in the sequence of packets for 
"Video 3" contain Program Clock Reference values, PCR A and 

25 PCR B , respectively. As explained above, each of the 

timestamps is a "snapshot" of the encoder system clock at the 
time the PCR was inserted into its respective Transport 
Packet of the sequence. Accordingly, a series of PCRs 
carried the sequence of Transport Packets formed from a 

30 particular Packetized Elementary Stream reflect the actual 
timebase of the single program of which that Packetized 
Elementary Stream is a member. 

Still referring to Figure 2, assume that Transport 
Packets A, B and C of the respective Transport Packet 

3 5 sequences for "Video 3" and "Audio 7" exit the Transport 

Steam multiplexer in the order A - C - B, as illustrated. In 
such a case, Transport Packet B has been delayed relative to 
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Transport Packet A by an amount, aT m . Consequently, the 
original timestamp, PCR B/ in Transport Packet B will no 
longer accurately reflect its relation in time to Transport 
Packet A. To compensate for such multiplexing delays or 
5 other variable delays, the MPEG- 2 Systems Committee suggested 
that the PCR of any Transport Packet that experiences such a 
delay be adjusted to account for the delay. As noted above, 
however, in situations where all packets experience a same 
constant delay, no adjustment of the PCRs is necessary. 
10 However, it is unlikely in most situations that all packets 
will experience an exactly constant delay. 

The adjustment of a PCR to compensate for a 
variable delay is illustrated graphically in Figure 2. As 
shown, the original PCR of Transport Packet B has been 
15 replaced with an adjusted value, PCR B ' . The adjusted 

timestamp value, PCR B ' , is obtained by adding the value of 
the delay, aT m , to the original timestamp value, PCR B . Thus, 
PCR B ' = PCR B + aT m . 

It should be noted that delays other than 
20 multiplexing delays may occur during transmission of a packet 
from the encoder to a reception site. For example, packets 
transmitted through an ATM network may experience delays at 
various switching nodes in the network. Compensation for 
these delays can be handled in the same manner. 
25 At a reception site, a decoder can be used to 

select one of the "programs" carried in an incoming Transport 
Stream for output or presentation at the reception site. The 
PCR's carried in the Transport Packets of a single selected 
"program" can be used to "slave" the decoder's system clock 
3 0 to the encoder's system clock for purposes of decoding that 
program. That is, the PCRs can be used to recreate or re- 
establish the timebase of that single program as the 
Transport Packets carrying the elementary stream data for 
that program arrive at the decoder. Stated generally, the 
3 5 PCRs may be used to perform clock recovery in the decoder. 

Figure 3 illustrates a model decoder for use in 
selecting a given program for output at a reception site. In 
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accordance with the times tamp technique described above, a 
clock generation circuit 58 in the decoder processes the PCR 
values carried in the Transport Packets of a selected program 
in order to re-establish the timebase of the selected program 
5 for decoding purposes. According to the model, an MPEG- 2 
Transport Stream is received by the decoder 4 0 and provided 
to a Transport Stream de-multiplexer/parsing unit 42. A 
user's program selection is provided to the demultiplexer 42 
via line 44. When a user selects a given program for output, 

10 the demultiplexer 42 begins extracting every incoming 

Transport Packet having a PID that matches one of the PIDs 
assigned to the elementary streams that make-up the selected 
program. For example, referring back to Figure 1, a 
subscriber may select Program 1 which consists of elementary 

15 streams "Video 1" and "Audio 1." Transport Packets carrying 
the Packet i zed Elementary Stream data for "Video 1" each have 
a PID of '10' , and the Transport Packets carrying the 
Packetized Elementary Stream data for "Audio 1" each have a 
PID of '23'. As successive packets of the Transport Stream 

20 are received, the demultiplexer 42 will extract every 
incoming Transport Packet having a PID of '10' or '23'. 
Extracted Transport Packets will then be parsed in order to 
reassemble the original Packetized Elementary Streams. 
Ultimately, the coded video and audio data of each Packetized 

25 Elementary Stream will be provided to respective buffers 48, 
54, and then to respective decoders 50, 56 which decode the 
data to produce analog video and audio signals for output to 
a display device. 

Additionally, as each Transport Packet of the 

30 selected program is received, the demultiplexer 42 determines 
whether that Transport Packet contains a PCR. If so, the PCR 
is extracted from the incoming packet and provided to the 
clock generation circuit 58 via line 59. As explained above, 
it is highly unlikely that the frequency of a decoder's 

35 system clock will be exactly the same as that of the original 
encoder, or that the decoder's system clock will be perfectly 
stable (i.e, will not drift). In accordance with the 
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timestamp approach described herein, the PCR values, which 
are sent periodically in the Transport Packets of the 
selected program, can be used to "reproduce" or "recover" the 
encoder system clock in the decoder, i.e., the PCRs can be 
5 used to re-establish the timebase of the selected program. 
Recovery of the encoder system clock in the decoder is 
performed by a clock generation circuit 58. Figure 3 
illustrates a model clock generation circuit that may be used 
in accordance with the timestamp technique described above. 

10 The model clock generation circuit 58 of Figure 3 

implements a straightforward phase -lock- loop (PLL) except 
that the reference and feedback terms are numbers (e.g., the 
values of counter 66 and received PCRs) . Upon initial 
acquisition of a user selected program, the counter 66 is 

15 loaded via line 61 with the first PCR received for that 
program. Thereafter, the PLL essentially operates as a 
closed loop. A voltage controlled oscillator (VCO) 64 having 
a nominal frequency substantially equal to that of the 
encoder system clock provides the decoder system clock 

20 signal. As the decoder system clock runs, the clock signal 

increments counter 66 which therefore represents the absolute 
time of the decoder system clock. As shown, the value of 
counter 66 is continuously fed back to a subtractor unit 60. 
Subtract or 6 0 compares the counter value with subsequent PCRs 

25 as they arrive in the Transport Stream Packets. Since a PCR, 
when it arrives, represents the expected value of the decoder 
system clock at the time that PCR is received, the difference 
between it and the value of counter 66 may be used to drive 
the instantaneous frequency of the VCO 64 to either slow down 

30 or speed up the decoder clock signal, as appropriate. A low- 
pass filter and gain stage (LPF) 62 is applied to the 
difference values from the subtractor 60 to produce a smooth 
control signal for the VCO 64. As can be appreciated, the 
continuous feedback provided by counter 66 and the periodic 

35 arrival of PCR values in the Transport Stream will ensure 

that the decoder system clock remains slaved to the encoder 
system clock. Thus, for the selected program, the encoder 
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system clock has been "reproduced" or "recovered" in the 
decoder, i.e., the original timebase of the single selected 
program has been re-established. 

Applicants, on behalf of their Assignee, have been 
5 actively involved the work of the MPEG- 2 Systems Committee in 
developing the MPEG- 2 Systems standard and have contributed 
to various aspects of the standard. As the MPEG- 2 Systems 
standard developed and it became apparent that the timestamp 
(i.e., PCR) approach described above would become part of the 

10 standard, Applicants realized that although the PCRs of each 
program must be adjusted during packet multiplexing to 
compensate for packet delays, some applications may require 
that the original PCR values of a given program, i.e., those 
found in an original sequence of Transport Packets generated 

15 by an encoder prior to multiplexing, be available at the end 
of a series of multiplexing stages. 

For example, the original PCRs may be used by 
downstream devices as an absolute time reference in order to 
trigger other events at precise times in much the same way 

20 that SMPTE time codes are used with analog video signals. 
Also, users of digital VCRs are likely to want to view and 
record one of the "programs" in an incoming Transport Stream 
at the same time. It is expected that digital VCRs will 
store programs retrieved from an incoming Transport Stream in 

25 their original Transport Packet sequences. That is, each 

sequence of Transport Packets carrying one of the Packetized 
Elementary Streams that "make-up" a single selected program 
will be stored directly on. the storage medium in the original 
consecutive order they had when first created by an encoder. 

3 0 Because the original sequence of Transport Packets is 

reestablished when the program is stored, the PCR values that 
were adjusted during transmission to account for multiplexing 
delays will no longer be valid since those delays are 
effectively eliminated when the original sequence of 

35 Transport Packets is reestablished. The adjusted PCRs 

therefore cannot be used to perform clock recovery during 
playback of a stored program. Rather, the original PCR 
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values (i.e., those originally inserted into each Transport 
Packet by an encoder prior to any multiplexing stages) are 
required since the original consecutive sequence of Transport 
Packets has been restored. 
5 Thus, as Applicants have recognized, if multiple 

programs are to be transmitted to a reception site using the 
timestamp technique described above, wherein the timestamp 
values used to establish the timebase of each program are 
adjusted to compensate for variable packet delays during 

10 multiplexing and/or transmission, a method is needed for 
preserving the original, unadjusted timestamp values for 
those applications requiring the original values. The 
present invention provides such a method. Applicants, on 
behalf of their Assignee, formally proposed the method of the 

15 present invention for inclusion in the MPEG-2 Systems 

standard in a paper presented to the International Standards 
Organization, entitled "A REVISED Proposal For MPEG-2 
Transport and Program Multiplex Syntax", MPEG 93/351 (March 
29, 1993), which is hereby incorporated by reference. A 

20 subsequent paper submitted by Applicants on behalf of their 
Assignee, entitled "Proposal to Include Delta PCRs in MPEG-2 
Transport Stream", MPEG 93/611 (July 1993), further urged the 
ISO to adopt the method of the present invention. 
Ultimately, the present invention, as defined by the appended 

25 claims, was substantially adopted as part of the MPEG-2 
Systems standard. 

SUMMARY OF THE INVENTION 

The present invention is particularly well suited 
3 0 for use in systems that transmit packets of information from 
a transmission site to a reception site wherein timestamp 
values are inserted into selected packets prior to 
transmission in order to facilitate dock recovery at a 
reception site, and wherein the timestamp values in each 
3 5 packet may require adjustment to compensate for delays 

experienced during multiplexing and/or transmission to the 
reception site. Applicants have recognized a need for a 
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method that preserves the original timestamp value in a 
packet to preserve the original timebase of a single program 
while also providing a means for tracking any delays 
experienced by the packet during various multiplexing and/or 
5 transmission stages. 

According to a preferred embodiment of the present 
invention, the method comprises the steps of (a) defining at 
least first and second fields within the packet; (b) 
inserting, at the transmission site, an original timestamp 

10 value in the first field of the packet, and thereafter not 

modifying the value in the first field; and (c) subsequent to 
performing step (b) , adding the value of any delay 
experienced by that packet to an initial value in the second 
field. At the reception site, the second field will reflect 

15 any delays experienced by the packet while the original 
timestamp value is preserved in the first field. In one 
embodiment, the second field is initialized to a value of 
zero prior to multiplexing and/or transmission of the packet. 

In an embodiment wherein the packet has a header, a 

20 payload and an adaptation field, step (a) preferably 
comprises defining the first and second fields in the 
adaptation field of the packet. According to another aspect 
of the invention, the adaptation field further contains first 
and second flags that correspond to the first and second 

25 fields, respectively, and step (a) further comprises the step 
of setting the first and second flags to a value indicative 
of the presence of the first and second fields within the 
adaptation field. 

3 0 BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing summary, as well as the following 
detailed description of the preferred embodiment, is better 
understood when read in conjunction with the appended 
drawings. For the purpose of illustrating the invention, 
3 5 there is shown in the drawings an embodiment that is 

presently preferred, it being understood, however, that the 
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invention is not limited to the specific methods and 
instrumentalities disclosed. In the drawings: 

Figure 1 graphically illustrates the generation of 
a Transport Stream from a plurality of Packet ized Elementary 
5 Streams in an encoder; 

Figure 2 graphically illustrates the concept of 
timestamp adjustment to account for multiplexing delays in a 
packet -based communications system; 

Figure 3 is a block diagram of an exemplary decoder 
10 for recovering a selected program from an incoming Transport 
Stream; 

Figure 4 graphically illustrates the content and 
arrangement of a Transport Packet in accordance with an 
embodiment of the present invention; 
15 Figure 5 is a flow diagram illustrating one aspect 

of the method of the present invention; 

Figure 6 is a flow diagram illustrating further 
aspects of the method of the present invention; 

Figure 7 is a block diagram of a device that 
20 incorporates circuitry for adjusting the PCR or DPCR field of 
a transport packet in accordance with the method of the 
present invention; and 

Figure 8 is a block diagram illustrating further 
details of the circuitry of Figure 7. 

25 

DETAILED DES CRIPTION OF THE PREFERR ED EMBQDTMTSTMT 

Referring to the drawings wherein like numerals 
indicate like elements throughout, Figure 4 illustrates the 
general content and arrangement of a Transport Packet 70, and 

30 more particularly, illustrates details of the content and 
arrangement of an "adaptation field" 74 of the Transport 
Packet 70 in accordance with an embodiment of the present 
invention. It should be noted that the content and 
arrangement of an adaptation field of an MPEG- 2 Transport 

3 5 Packet, as specified in the aforementioned MPEG- 2 Systems 
Committee Draft, while similar, is not identical to that 
illustrated in Figure 4 . 
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As shown in Figure 4, the Transport Packet 70 
comprises a header portion 76, a payload section 72, and the 
"adaptation field" 74 mentioned above. The Transport Packet 
header 76 contains a Packet ID (PID) and other transport- 
5 related information (not shown) . One field in the header 
(not shown) is used to indicate whether the packet contains 
an adaptation field 74. As originally proposed by others and 
ultimately adopted as part of the MPEG- 2 Systems standard, an 
adaptation field may be "opened" in any Transport Packet to 

10 provide a convenience "window" for carrying both MPEG-related 
and private information of relevance to either the Transport 
Stream or the elementary stream data carried in the payload 
section of that Transport Packet. When present, an 
adaptation field 74 may contain a number of fields and flags. 

15 According to the present invention, a first field 

88 may be defined within the adaptation field 74 of a 
Transport Packet 70 to implement a PCR segment for carrying a 
PCR value within the Transport Packet 70. As explained 
above, however, not all Transport Packets in a given 

2 0 Transport Stream will contain a PCR value, and therefore, a 

PCR flag 82 may be used to indicate the presence or absence 
of a PCR segment 88 within the adaptation field 74 . Although 
the PCR segment 88 may have any suitable format without 
deviating from the spirit and scope of the present invention, 
25 the MPEG- 2 Systems Committee settled on a PCR format 

comprising a thirty-three bit base component and a nine bit 
extension component . Accordingly, as illustrated in Figure 
4, the PCR segment 88 preferably comprises a thirty-three bit 
base field 90 and a nine bit extension field 94. As further 

3 0 specified by the MPEG- 2 Systems Committee, the nine bits of 

the PCR extension 94 implement a modulo 3 00 counter that 
increments at a rate of 27 MHz. At each modulo 300 
"rollover", the count in the thirty-three bit base portion 90 
is incremented. The base portion 90 of the PCR segment 
35 therefore represents a 90 KHz clock rate. As explained 

above, a PCR is an actual "snapshot" of the encoder system 
clock at the time the PCR was inserted into the Transport 
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Packet. In particular, as ultimately defined in the MPEG-2 
Systems Committee Draft, a PCR value indicates the value of 
the encoder system clock at the time the byte containing the 
last bit of the PCR base portion 90 was inserted into the 
5 Transport Packet. Stated otherwise, in an incoming Transport 
Stream, the value of a PCR represents the intended time of 
arrival of the byte containing the last bit of the PCR base 
portion 90. 

As explained above, in order to provide accurate 

10 timebase recovery during reception of a transmitted program, 
the PCR values carried in the Transport Packets of that 
program must be adjusted at every multiplexing stage in the 
transmission system to compensate for any multiplexing delays 
imposed by a multiplexer. However, as Applicants have 

15 recognized, it may also be necessary in some applications to 
preserve the original PCR values for use by the decoder. The 
present invention satisfies this need by providing a 
mechanism for adjusting PCRs values to account for 
multiplexing delays while at the same time preserving the 

2 0 original PCR values. 

According to the present invention, as illustrated 
in Figure 4, a second field 96 may be defined within the 
adaptation field 74 in order to implement a Delta_PCR (DPCR) 
segment. A DPCR flag 84 may be provided for indicating the 

25 presence of a DPCR segment 96 within the adaptation field. 
According to the present embodiment, the DPCR segment 96 has 
a structure similar to the PCR segment 88 and comprises a 
twenty-bit base component 98 and a nine bit extension 
component 100. The DPCR base 98 represents a 90 KHz clock 

30 component, and the DPCR extension 100 represents a 27 MHz 

clock component. With a 90 KHz clock frequency, the twenty- 
bit DPCR base field 98 can accumulate approximately 11.5 
seconds of delay before rol ling- over . If a greater amount of 
accumulated delay is expected, the DPCR base field 98 can be 

35 made larger. For example, the DPCR base field 98 can have 
the same 33 -bit format as the PCR base field 90. 
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Further in accordance with* the present invention, 
the PCR segment 88 in an adaptation field further comprises a 
PCR modify flag 92. The PCR modify flag 92 is used to inform 
a multiplexer (e.g., multiplexer 22 of Figures 1 and 2) that 
5 the PCR base and extension fields 90, 94 cannot be modified. 

Although not shown in detail, an adaptation field 
74 may also contain other fields. For example, an adaptation 
field 74 may contain an 8-bit length field 78 for specifying 
the overall length, in bytes, of the adaptation field 74. 

10 Any number of other fields (not shown) may also be defined 
within the adaptation field 74, and corresponding flags 86 
may be used to indicate the presence or absence of these 
fields in a particular Transport Packet, in much the same way 
that the PCR and DPCR flags 82, 84 are used to indicate the 

15 presence or absence of the PCR and DPCR segments 88, 96 of 
the present invention. 

According to the method of the present invention, 
when it is desired to preserve the original PCR value in a 
Transport Packet 70 while also providing a means for tracking 

20 any variable delays experienced by the packet during 

multiplexing or transmission, an encoder sets the PCR and 
DPCR flags 82, 84 in the adaptation field 74 of the Transport 
Packet 70 to define a PCR segment 88 (first field) and a DPCR 
segment 96 (second field) within the adaptation field 74. 

25 Prior to multiplexing, the encoder generates an original PCR 
(i.e., timestamp) from the encoder system clock and inserts 
the original PCR into the base and extension fields 90, 94 of 
the PCR segment 88. The PCR modify flag 92 is then set to 
inform subsequent multiplexing stages or other downstream 

30 devices that the PCR base and extension fields 90, 94 may not 
be modified. As the Transport Packet 70 progresses through 
various multiplexing stages and other devices in the. 
communications system, the DPCR segment 96 is used to 
maintain an accumulation of the delays imposed on the packet 

35 at such devices. Specifically, whenever a multiplexing stage 
or other device imposes a variable delay on the Transport 
Packet 70, a value representing the magnitude of the delay is 
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added to the current value in the DPCR segment 96 . Each 
multiplexing stage or other device will have a local system 
clock operating at a nominal frequency of 27 MHz, the nominal 
frequency of the encoder's system clock. The delay, aT m , 
5 imposed upon the Transport Packet 7 0 at a given multiplexing 
stage or other device may be calculated as follows: 

aT m = LSCR(t out ) - LSCR(t in ) - D 

where, 

LSCR(t out ) is the value of the local system 
10 clock of the multiplexer when the Transport Packet 

reaches the output of the multiplexer ; 

LSCR(t in ) is the value of the local system 
clock when the Transport Packet enters the 
mul t iplexer ; and 

15 D is a pre -determined constant delay that is 

imposed on all Transport Packets as they pass 
through the multiplexer. 

Once calculated, the measured delay, aT m , may be added to the 

current value of the accumulated delay in the DPCR segment 

2 0 96. Because the accumulated value in the DPCR segment 96 

comprises a 20 -bit base component representing a 90 KHz clock 
frequency, and a 9-bit extension component representing a 27 
MHz clock frequency, the delay measured at a multiplexer 
stage, aT m , must be converted to the base/extension format 
25 before adding the value to the current accumulation in the 
DPCR segment. Conversion can be performed in the following 
manner : 

AT M (base) = int [aT m /300] 
aT m (extension) = aT m - AT M (base) 

3 0 where , 

aT m is the delay value prior to conversion; 

AT M (base) is the 2 0 -bit base component of the 
delay value after conversion; and 

aT m (extension) is the 9-bit extension component 
3 5 of the delay value after conversion. 

At a decoder, the accumulated delay value in the PPCR segment 

96 may be added to the original PCR value in the PCR segment 

88 to obtain an adjusted PCR value. In this manner, the 

original PCR value may be preserved in the PCR segment 88. 
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Figure 5 is a flow diagram illustrating a number of 
steps to be performed by an encoder during generation of 
Transport Packets in accordance with the method of the 
present invention. During generation of a Transport Packet, 
5 the encoder will determine whether the Transport Packet is to 
carry a timestamp (PCR) , as shown at step 110, If so, an 
adaptation field is established within the Transport Packet 
at step 111, and control then passes to step 112. The 
presence of an adaptation field may be established by setting 

10 an appropriate bit in the header of the Transport Packet. At 
step 112, the encoder determines whether the original PCR 
should be preserved. Whether the original PCR should be 
preserved depends on the application, and the decision at 
step 112 will normally be pre-programmed in the encoder. 

15 When there is no need to preserve the original PCR, 

control passes to step 114 where the encoder sets the PCR 
flag in the adaptation field to establish a PCR segment. At 
step 116, the encoder generates an appropriate PCR value and 
inserts the PCR value into the PCR segment. As explained 

20 above, a PCR represents an actual sample or "snapshot" of the 
encoder system clock at the time the PCR is inserted into the 
PCR segment of the Transport Packet. At step 118, the PCR 
modify flag in the PCR segment is set to inform subsequent 
multiplexing stages that the PCR value in the PCR base and 

25 extension fields may be modified directly. That is, any 
delays measured at subsequent multiplexing stages may be 
added directly to the value in the PCR segment. 

Consequently, the original PCR value is not preserved in this 
case . 

30 If, however, at step 112 it is determined that the 

original PCR value should be preserved, control will pass to 
step 120 where the PCR and DPCR flags in the adaptation field 
are each set to establish both PCR and DPCR segments. At 
step 122, the encoder generates an appropriate PCR value and 

35 inserts the PCR value into the PCR segment. The PCR modify 
flag is then set to a value of '0' at step 124 to indicate 
that the PCR segment may not be modified by any downstream 
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multiplexers or other devices. At step 126, the base and 
extension fields of the DPCR segment are initialized to a 
value of zero. Further processing of the Transport Packet 
may then continue as required. 
5 Figure 6 is a flow diagram illustrating the steps 

that are performed at each multiplexing stage (or other 
device that imposes variable delays) in accordance with the 
method of the present -invention. As a Transport Packet is 
received by the multiplexer, the multiplexer examines the 

10 Transport Packet header to determine if an adaptation field 
is present in the packet, as shown at step 130. If an 
adaptation field is present, then control passes to step 132 
where the multiplexer examines the PCR flag to determine 
whether a PCR segment is present in the adaptation field. If 

15 a PCR segment is present, then the multiplexer examines the 
PCR modify flag at step 134. If the PCR modify flag 
indicates that the PCR base and extension fields may be 
modified (i.e., PCR Modify Flag = 'I'), then control passes 
to step 136. 

20 At step 13 6, after inserting the Transport Packet 

in a position within the outgoing multiplexed data stream, 
the multiplexer determines the amount of delay, aT m , imposed 
upon the packet during the multiplexing operation. The delay 
may be calculated as described above. At step 138, the 

25 measured delay is converted to the base/extension format of 
the PCR segment. At step 140, the current value in the PCR 
base and extension fields, PCR current , is adjusted by adding 
the measured delay value, aT m , to the current value. The 
Transport Packet then exits the multiplexer in the outgoing 

3 0 multiplexed data stream. In this case, the original PCR 
value is not preserved. 

If at step 134, it is determined that the PCR 
modify flag is set to '0', indicating that the PCR base and 
extension fields may not be modified, then control passes to 

35 step 14 2 where the multiplexer determines whether a DPCR 
segment has been provided in the adaptation layer. If no 
DPCR segment is provided, then the multiplexer simply allows 
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the Transport Packet t o exit the multiplexer without tracking 
the delay imposed on that packet. Of course, the original 
PCR value is still present in the PCR segment. This case 
will only occur in applications in which delay tracking is 
5 not required at all, and only the original PCR value is 
needed. 

If a DPCR segment is provided in the adaptation 
field, then at step 144, after inserting the Transport Packet 
in a position within the outgoing multiplexed data stream, 

10 the multiplexer determines the amount of delay, aT m , imposed 
upon the packet during the multiplexing operation. At step 
146, the measured delay is converted to the base/extension 
format of the DPCR segment. At step 14 8, the current 
accumulated delay value in the DPCR base and extension 

15 fields, DPCR^^, is adjusted by adding the measured delay 
value, aT m , to the current value. The Transport Packet then 
exits the multiplexer in the outgoing multiplexed data 
stream. In this case, the original PCR value is preserved in 
the PCR segment while at the same time, an accumulation of 

20 the multiplexing delays imposed on the Transport Packet is 
maintained in the DPCR segment. As explained above, if an 
adjusted PCR value is ultimately needed, the value in the 
DPCR segment can always be added to the original PCR value at 
that time without destroying the original PCR value for other 

25 applications. 

Figure 7 is a block diagram of a device 150, such 
as a multiplexing stage, that incorporates circuitry for 
adjusting the PCR or DPCR field of a transport packet to 
reflect a variable delay imposed on that packet as it passes 

30 through the device 150. In particular, the circuitry 

described hereinafter may be employed to implement steps 144- 
148 and 136-140 of Figure 6. As shown in Figure 7, the 
circuitry comprises a first PCR/DPCR modifier module 154 
connected to the input 152 of the device 150, and a second 

3 5 PCR/DPCR modifier module 154' connected at the output 16 0 of 
the device. The circuitry of the particular device 150, 
which is assumed to impose a variable delay on the Transport 
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Packet as it passes through the device 150, is represented by- 
block 156. A local system clock signal provided on line 164, 
which operates at a nominal frequency of 27 MHz, drives a 
local system clock reference counter 162 that increments at 
5 each cycle of the system clock signal. Thus, the value in 
the counter 162 represents the absolute value of the local 
system clock. The value of the local system clock reference 
counter 162 is provided on line 166 to both PCR/DPCR modifier 
modules 154, 154'. In the present embodiment, the value of 

10 the system clock reference counter 166 is provided to the 

PCR/DPCR modifier modules 154, 154' in the 33 -bit base/9-bit 
extension format described above. 

A Transport Packet enters the device 150 at input 
152 and passes directly to the input 154a of the first 

15 PCR/DPCR modifier module 154 . As described hereinafter in 

greater detail, assuming that PCR/DPCR adjustment is enabled, 
the PCR/DPCR modifier circuit 154 subtracts the value of the 
local system clock reference counter 162 from either the PCR 
segment (when the original program clock reference is not to 

2 0 be preserved) or the DPCR segment (when the original program 
clock reference is to be preserved) . The result of the 
subtraction is then inserted in place of the previous value 
in the appropriate PCR or DPCR segment as the Transport 
Packet leaves the module 154 . The Transport Packet then 

2 5 passes through the internal circuitry (block 156) of the 

device 150 where the packet is assumed to experience a 
variable delay. As the Transport Packet is passing through 
the device 150, the local system clock reference counter 162 
is incrementing at each cycle of the local system clock 

3 0 signal. 

Before exiting the device 150, the Transport Packet 
passes through the second PCR/DPCR modifier module 154'. As 
explained hereinafter in greater detail, the second PCR/DPCR 
modifier module 154' adds the updated value of the local 
35 system clock reference counter 162 to the PCR (original PCR 
not preserved) or DPCR (original PCR preserved) segment of 
the Transport Packet under consideration. The result is 
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copied over the value the segment had upon entering the 
second module 154'. As a result of this addition step, the 
new value in the particular segment (PCR or DPCR) will be 
equal to the value the Transport Packet contained upon 
5 entering the device 150 plus the value of the variable delay 
the Transport Packet experienced upon passing through the 
device . 

As an example, assume a Transport Packet enters the 
device and that the original PCR value is to be preserved and 

10 any variable delay is to be accumulated in the DPCR segment 
of the Transport Packet. Upon entering the device 150, the 
DPCR segment has an initial value, DPCR in . Upon exiting the 
first PCR/DPCR module 154, the DPCR segment will have a 
modified value, DPCR^, equal to its initial value, DPCR in , 

15 minus the value of the local system clock reference, 

LSCR(t in ), at the time the packet entered the first module 
154. Thus, 

DPCR^a = DPCR in - LSCR(t in ) . 
While the transport packet is passing through the device 150, 

20 the local system clock reference counter 162 is updating at a 
rate of 27MHz. Before exiting the device 150, the transport 
packet .will pass through the second module 154' which will 
add the updated value of the local system clock reference, 
LSCR(t out ), to the modified DPCR value, DPCR^, to produce an 

25 adjusted value, DPCR adj# that reflects the variable delay 
imposed on the Transport Packet as it passed through the 
device 150. That is, 

DPCR adj = DPCR,** + LSCR(t out ) 

- (DPCR in - LSCR(t in )) + LSCR(t out ) 

30 = DPCR in + (LSCR(t out ) - LSCR(t in )) 

where, LSCR (t out ) -LSCR (t in ) represents the variable delay, aT d , 
imposed by the device 150. In cases where the original 
program clock reference does not have to be preserved, the 
foregoing operations could be performed directly on the PCR 

35 segment of the transport packet. 

Figure 8 is a block diagram illustrating details of 
a PCR/DPCR modifier module that may be used to implement both 
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of the modules 154 and 154' of Figure 7 . As shown, the 
module has an input 167a for receiving a Transport Packet of 
an incoming Transport Stream. Input 16 7a forms inputs 154a 
and 154a ' of the respective modules 154, 154' of Figure 7. A 
5 Transport Packet entering the module 167 via line 167a is 

provided to a stream parser 168, a PCR/DPCR extraction module 
174 and a data pipeline 178. When PCR/DPCR adjustment is to 
be performed, an appropriate signal is provided via line 170 
to enable the stream parser 168. Once enabled, the stream 
10 parser 168 parses the header of the incoming Transport Packet 
to determine first whether the Transport Packet contains an 
adaptation field (step 130 of Figure 6) . If so, the stream 
parser examines the PCR flag in the adaptation field (step 
132) . If the PCR flag indicates that a PCR segment is 
15 present in the adaptation field of the Transport Packet, the 
stream parser then examines the PCR modify flag in the PCR 
segment (step 134) . Recall from the description of Figure 6 
that if the PCR modify flag is set, then the PCR segment can 
be adjusted directly, i.e., the original PCR is not 
20 preserved. If, however, the PCR modify flag is not set, then 
the PCR segment cannot be modified, and the stream parser 168 
then determines whether a DPCR segment is present. If so, 
then the DPCR segment is to be modified. 

Once the appropriate segment (PCR or DPCR) has been 
25 identified for modification, the stream parser 168 provides 
an appropriate signal to the PCR/DPCR extraction unit 174 
which extracts the appropriate segment. The present example 
assumes that both the PCR and DPCR segments have the 3 3 -bit 
base/9-bit extension format. As mentioned above, however, 
3 0 the DPCR segment can be smaller if desired. The extracted 
PCR or DPCR is provided to one input of an adder/subtractor 
unit 176. The local system clock reference, LCSR, is 
provided to the other input of the adder/subtractor unit 176 . 
The adder/subtractor unit 176 can be set, via a "mode" input 
35 182, to perform either addition or subtraction. When the 
module 167 is used to implement the first module 154 of 
Figure 7, the mode is set for subtraction. When the module 
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167 is used to implement the second module 154' of Figure 7, 
the mode is set for addition. The result of the addition or 
subtraction is provided via line 184 to one input of a 
multiplexer 180. The other input of the multiplexer receives 

5 Transport Packet data from the data pipeline 178 via line 
186. The multiplexer output is controlled by the multiplex 
control signal provided on line 172 from the stream parser 

168 . 

The data pipeline 178 receives the Transport Packet 

10 on line 167a and delays the propagation of the Transport 
Packet, if necessary, for a sufficient amount of time to 
allow the addit ion/subtraction to be performed by the 
adder/subtractor unit 176. Initially, line 186 is selected 
for output from the multiplexer 180, and therefore, the data 

15 of the Transport Packet begins to pass through the 

multiplexer to output line 188. As the segment to be 
modified (PCR or DPCR) reaches the input of the multiplexer 
180, the output of the multiplexer 180 is switched to line 
184 so that the modified value replaces the previous segment 

20 value. Once the modified data for the PCR/DPCR segment has 

passed through the multiplexer, the output of the multiplexer 
switches back to line 186 in order to output the remainder of 
the Transport Packet on line 188. Thus, the multiplexer 180 
serves as a drop- add multiplexer to replace the value of the 

25 PCR or DPCR segment in the received Transport Packet with the 
result of the addition/subtraction operation. The module 167 
operates as described above on each successive Transport 
Packet of an incoming Transport Stream. 

As the foregoing illustrates, the present invention 

3 0 is directed to a method for preserving the original timestamp 
in a packet of data while maintaining, if desired, an 
accumulation of any multiplexing delays imposed on the packet 
at various stages of a multiplexed digital transmission 
system. In a system that relies on timestamp values to 

35 establish the timebase of a digital program in a decoder, the 
present invention provides a means for preserving the 
original timebase of that single program. It is understood, 
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however, that changes may be made to the embodiments 
described above without departing from the broad inventive 
concepts thereof. For example, while the method of the 
present invention is particularly well suited for tracking 

5 multiplexing delays, the same method may be used at other 
downstream devices, such as network switching nodes, to 
accumulate delays imposed by those devices. Accordingly, 
this invention is not limited to the particular embodiments 
disclosed, but is intended to cover all modifications that 

0 are within the scope and spirit of the invention as defined 
by the appended claims. 
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WHAT IS CLAIMED IS: 

1. In a system for transmitting packets of 
information from a transmission site to a reception site 
wherein timestamp values are inserted into selected packets 

5 prior to transmission in order to facilitate clock recovery 
at a reception site, the timestamp values inserted into the 
selected packets at the transmission site defining original 
timestamp values, and further wherein the original timestamp 
value in a given packet may require adjustment at the 
10 reception site to account for delays experienced by that 

packet, a method of preserving the original timestamp value 
of a packet for use at the reception site, said method 
comprising the steps of: 

(a) defining at least first and second fields 
15 within the packet; 

(b) inserting, at the transmission site, an 
original timestamp value in the first field of the packet, 
and thereafter not modifying the value in the first field; 
and 

20 (c) subsequent to performing step (b) , adding the 

value of a delay experienced by that packet to an initial 

value in the second field, 

whereby the original timestamp value in the first 

field is preserved for use at the reception site and the 
25 value in the second field may be used, if necessary, to 

compensate for the delay experienced by the packet . 

2. The method of claim 1 further comprising the 
step of initializing the second field of the packet to a 

3 0 value of zero, whereby said initial value is zero. 

3 . The method of claim 1 wherein the packet has a 
header, a payload and an adaptation field, and further 
wherein step (a) comprises defining said first and second 

35 fields in the adaptation field of the packet. 
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4. The method of claim 3 wherein the adaptation 
field further contains first and second flags corresponding 
to first and second fields, respectively, and wherein step 
(a) further comprises the step of setting the first and 

5 second flags to a value indicative of the presence of said 
first and second fields within the adaptation field. 

5. In a multiplexed communications system for 
transmitting packets of information from a transmission site 

10 to a reception site wherein timestamp values are inserted 

into selected packets prior to multiplexing and transmission 
in order to facilitate clock recovery at a reception site, 
the timestamp values inserted into the selected packets at 
the transmission site defining original timestamp values, and 

15 further wherein the original timestamp value in a given 
packet may require adjustment to account for delays 
experienced by that packet during multiplexing and 
transmission, a method of preserving the original timestamp 
value of a packet for use at the reception site, said method 

20 comprising the steps of: 

(a) defining at least first and second fields 
within the packet ; 

(b) inserting, at the transmission site, prior to 
multiplexing and transmission, an original timestamp value in 

25 the first field of the packet, and thereafter not modifying 
the value in. the first field; and 

(c) during multiplexing and transmission of the 
packet to the reception site, adding the value of any delay 
experienced by the packet to an initial value in the second 

30 field, 

whereby the original timestamp value in the first 
field is preserved for use at the reception site and the 
value in the second field may be used, if necessary, to 
compensate for any delays experienced by the packet during 
3 5 multiplexing and transmission. 
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6 . The method of claim 5 further comprising the 
step of initializing the second field of the packet to a 
value of zero, whereby said initial value is zero. 

5 7 . The method of claim 5 wherein the packet has a 

header, a payload and an adaptation field, and further 
wherein step (a) comprises defining said first and second 
fields in the adaptation field of the packet. 

10 8. The method of claim 7 wherein the adaptation 

field further contains first and second flags corresponding 
to first and second fields, respectively, and wherein step 
(a) further comprises the step of setting the first and 
second flags to a value indicative of the presence of said 

15 first and second fields within the adaptation field. 
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